The 3rd generation Partnership Project (3GPP) organization specifies the architecture of mobile cellular networks such as like Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS). Third-generation mobile systems (3G), based on WCDMA radio-access technology, such as UMTS, are being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology was the introduction of the High-Speed Downlink Packet Access (HSDPA) and of the enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA). In a longer time perspective it is however necessary to be prepared for further increasing user demands and be competitive against new radio access technologies. To meet this challenge, 3GPP has initiated a study item leading to Evolved 3GPP Packet Switched Domain, which is also known under the name Evolved Packet System (EPS). The EPS combines an Evolved Packet Core (EPC) network that is able to connect a new generation of an access network technology called Evolved Universal Terrestrial Radio Access Network (E-UTRAN) as well as the pre-successor of the E-UTRAN called Universal Terrestrial Radio Access Network (UTRAN). Another broadly used term for E-UTRAN (and having the same meaning) is Long Term Evolution (LTE). LTE is designed to meet the subscriber and network operator needs for high speed data and media transport as well as high capacity voice support to the next decade.
An LTE network architecture including network entities and interfaces between them is exemplified in FIG. 1. As can be seen in FIG. 1, the LTE architecture supports interconnection of different radio access networks (RAN) such as UTRAN or GERAN (GSM EDGE Radio Access Network), which are connected to the EPC via the Serving GPRS Support Node (SGSN). Some of the entities and interfaces are described below for facilitating the understanding of the exemplary embodiments of the present invention.
In a 3GPP mobile network, the mobile terminal 110 (called User Equipment, UE, or device) is attached to the access network via the Node B (NB) in the UTRAN and via the evolved Node B (eNB) in the E-UTRAN access. The NB and eNB 120 entities are known as base station in other mobile networks. A common denotation for the NB and eNB used in this document is (e)NB. There are two data packet gateways located in the EPS for supporting the UE mobility—Serving Gateway (SGW) 130 and Packet Data Network Gateway 160 (PDN-GW or shortly PGW). The SGW terminates the interface towards the radio access networks, e.g. the UTRAN or the E-UTRAN. The mobility within one radio access network (UTRAN or E-UTRAN) is access specific. The mobility within the EPC is managed by the PGW. The mobility management in the EPC between the PGW and the SGWs can be based either on the Proxy MIPv6 (PMIP) protocol or on the GPRS Tunneling Protocol (GTP). The interface between the SGW and the PGW is called S5 and it can be based either on the GTP or the PMIPv6 protocol. The PGW further performs IP address allocation to the UE and packet filtering (e.g. deep packet inspection, packet screening) in order to map the UE's traffic to appropriate Quality of Service (QoS) level.
Assuming the E-UTRAN access, the eNB entity 120 may be connected through wired lines to one or more SGWs via the S1-U interface (“U” stays for “user plane”) and to the Mobility Management Entity 140 (MME) via the S1-MMME interface. The S1-U interface is based on the GTP protocol and the S1-MME interface is based on the S1-AP protocol.
The SGSN 150 and MME 140 are also referred to as serving core network (CN) nodes. These network nodes maintain the context of the UE in the network, which means the security parameters, parameters used for the mobility management (e.g. in which are or cells the UE is camping, if the UE is reachable) and parameters used for the session management (SM) such as QoS parameters describing the communication sessions.
The SGW 130 routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME 140 is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signalling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME 140 is the termination point in the network for ciphering/integrity protection for NAS signalling and handles the security key management. Lawful interception of signalling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME 140 from the SGSN 150. The MME also terminates the S6a interface towards the Home Subscriber Server (HSS) for roaming user equipments.
The E-UTRAN comprises eNodeBs, providing the E-UTRA user plane by means of Packet Data Control Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC) and physical layer protocols (PHY) as well as control plane by means of Radio ResourceControl (RRC) protocol terminations towards the UE. The eNodeB (eNB) hosts the PHY, MAC, RLC and PDCP layers including the functionality of user-plane header-compression and encryption. The service the RLC layer provides in the control plane between UE and eNodeB is called Signaling Radio Bearer (SRB). In the user plane, the service provided by RLC layer between the UE and the eNodeB is called a Radio Bearer (RB) or Data Radio Bearer (DRB). The eNB also offers RRC functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
Amongst others, higher layer, i.e. Non Access Stratum (NAS), messages are carried by the RRC messages (e.g. using RRC Direct Information Transfer message) between the UE and the eNodeB. The Non Access Stratum is a functional layer running between the UE and the Core Network (CN) and located above the RRC. Furthermore, the NAS is the functional grouping of protocols aimed at Call Control (CC) for circuit switched voice and data, at Session Management (SM) for packet switched data and Mobility Management (MM) and at Short Message Services (SMS) for packet switched and circuit switched domains. The control messages the NAS layer generates are called NAS messages. Such messages are for example used to control Mobility Management, Session Management, SMS Transport and Call Management. NAS messages are transported transparently through the Access Stratum layers (layers 3-2-1, RRC, PDCP, RLC, MAC, PHY) that include the function and protocols to support the NAS transport. In order to send the initial non-access stratum message, the user equipment first establishes a Radio Resource Control (RRC) connection to the eNodeB over the air interface (Uu interface). During the RRC connection establishment the user equipment and eNodeB get synchronized and establish the Signalling Radio Bearers (SRB) that can be used for the transport of the non-access stratum messages.
The Access Stratum is the functional grouping of protocols specific to the access technique, in this case, the RRC, PDCP, RLC, MAC and PHY. It includes protocols for supporting transfer of radio-related information, for coordinating the use of radio resources between UE and access network, and for supporting access from the serving network to the resources provided by the access network. The Access Stratum offers services through Service Access Points (SAP) to the Non-Access Stratum (CN-related signaling and services), i.e. provides the Access Link between UE and core network, which consists of one or more independent and simultaneous UE-core network radio access bearer services, and only one signaling connection between the upper layer entities of UE and the core network.
When the UE is switched-off or not attached to the mobile network, the UE is in DEREGISTERED state. In DEREGISTERED state, no EMM context exists and the UE location is unknown to an MME and hence it is unreachable by an MME.
When a mobile terminal (or user equipment, UE) is attached to the network, the UE is in the so called REGISTERED state, i.e. EPS Mobility Management (EMM) context has been established and a default EPS bearer context has been activated in the network and in the UE. When the UE is REGISTERED to mobile network, the UE can be in two different connections management states: IDLE and CONNECTED state.
The UE is in IDLE state when there is no data for transmission and the radio resources are released, but the UE still has a valid IP configuration. A UE in IDLE state doesn't have a radio association (i.e. Radio Resource Connection, RRC) with the eNB, and therefore, there are no established signalling and data radio bearers. Further, there is no Non-Access Stratum (NAS) signalling connection between the UE and the network (e.g. to the MME) and also, there is no S1-U connection between the eNB and the SGW.
When the UE is in CONNECTED state and the network (usually the eNB) detects that the UE is not sending/receiving data for a certain period of time, the network (usually the eNB) decides to release the radio resources and the S1 connection. As a result, the UE transits from CONNECTED to IDLE state. Also the MME changes its internal state for the UE to IDLE and informs the SGW to release the S1-U connection to the eNB.
The above described IDLE and CONNECTED states are related to the NAS layer state diagram. On the other hand, in the AS layer the IDLE and CONNECTED states are also defined. The AS IDLE and CONNECTED states are similar but not completely analogical to NAS IDLE and CONNECTED states, i.e. if the RRC connection is established, the AS state is CONNECTED, otherwise if the RRC connection is released, the AS state is IDLE. Not always when the AS state is CONNECTED, the NAS state is also CONNECTED (e.g. for TAU procedure without active flag). The establishment of the RRC connection, and thus, the transition to AS CONNECTED state, is initiated by the UE, as only the UE can send “RRCConnectionRequest” message. The UE initiates the RRC connections establishment either due to the availability of uplink data or uplink signalling; or due to paging from the network in order to receive downlink data or downlink signalling.
Recently, 3GPP has started an activity on Network Improvements for Machine Type Communication (MTC). The service requirements have been described in 3GPP TS 22.368, v.11.3.0, October 2011, “Service requirements for Machine-Type Communications (MTC)”, freely available on www.3gpp.org, while the study of possible architecture solutions can be found in 3GPP TS 23.888, v.1.5.0, October 2011, “System Improvements for Machine-Type Communications (MTC)”, freely available on www.3gpp.org. The MTC terminals or MTC devices are characterized in that they are usually not operated by a human being. Rather, the communication peer is another machine such as a so called MTC server or another MTC terminal(s). As the MTC devices can be also mobile terminals as specified by the 3GPP, a more general notification like “UE” is also used throughout this invention, so that the MTC device, terminal or UE are used interchangeable.
The MTC has some particular features which differ from the usual human-to-human communication. 3GPP tries to identify these particular features in order to optimize the network operations. These specifics are called “MTC features”. For instance, an MTC device typically sends or receives smaller amounts of data. Another feature of the MTC devices and 3GPP core network (CN) shall be the ability to allow an external server (MTC server) to trigger the MTC device to initiate a communication with the MTC server. This is enabled by a so-called “device triggering”. For the current state of standardization the Device Triggering is specified for MTC Devices which are attached to the network, i.e. the devices are online. Thus, it is often referred to it as to “Online Device Triggering”. The Device Triggering is initiated by the MTC server and can be performed by different means.
A first possibility is to use a usual Short Message Service (SMS). Accordingly, the MTC server generates an SMS message and sends it to the Short Message Serving Center (SM-SC). The SM-SC forwards the message within the CN to the MSC or SGSN 150 for delivery to the UE.
Network architecture according to the present state of standardization (cf. 3GPP TS 23.682 “Architecture Enhancements to facilitate communications with Packet Data Networks and Applications”, v0.1.0, November 2011, freely available in www.3gpp.org), including entities which may be involved in MTC message triggering is exemplified in FIG. 2. In particular, the MTC server 210 may generate an SMS and send it to the SM-SC 270, which forwards the message to a network node 240 such as MSC or SGSN for delivery over RAN to the UE 260.
Another possibility is that the MTC server 210 sends the Device Trigger request to a dedicated entity in the 3GPP CN, called MTC Inter-Working Function (MTC-IWF). The MTC-IWF 220 may then apply different Device Trigger transport mechanisms. For instance, the device trigger may be transmitted over a T4 interface (cf. “indirect model” in FIG. 2). For that purpose the MTC-IWF 220 generates an SMS-conform information and sends it to the SM-SC 270 entity. The transport from the SM-SC 270 to UE 260 is then based on the usual SMS transmission. A signalling flow of Device Trigger transmission as an SMS can be found in 3GPP TS 23.682, Section A.3.
The device trigger may alternatively be transmitted over the T5 interface. For that purpose the MTC IWF 220 sends the Device Trigger request to the serving CN node over a direct interface (cf. “direct model” in FIG. 2). The serving CN node carries the Device Trigger request message to the UE over a general purpose NAS signalling transport.
The Device Trigger request sent from the MTC server can carry two types of information:                information to be used by the network to deliver the Device Trigger, and        information destined to the MTC Device and opaque (transparent) to the network.        
The information to be used by the network to deliver the Device Trigger may include, for instance, External ID of the UE (used by the MTC server and MTC-IWF to identify the UE that shall be triggered), MTC server ID (used by the network to contact the MTC server, e.g. when delivering the Device Trigger Delivery report), priority/urgency of the Device Trigger, Validity time for the Device Trigger and/or others.
The information destined to the MTC Device and opaque (transparent) to the network may include, for instance, the identity of the application in the MTC device, target MTC server/application ID (used by the MTC device to contact the MTC server/application, e.g. the IP address and/or port or FQDN of the MTC server/application), particular QoS parameter, priority or urgency of the UL data, optionally MTC application specific information (of limited size, e.g. what information/parameters should be reported by the MTC device), optionally measurement time (i.e. how long shall the MTC device gather information before initiating the reporting), and/or others.
The unsuccessful transmission of the Device Trigger over T4 interface can be seen in section A.3.2 of 3GPP TS 23.682. It is similar to the unsuccessful transmission of SMS, where the SMS is stored in the SM-SC until the UE is reachable. FIG. 3 shows the signalling flow of the case when the Device Trigger is stored in the network (SM-SC) for later transmission. Steps 1 to 7 refer to the corresponding steps of FIG. A.2-1 in 3GPP TS 23.682. The storing of the Device Trigger is performed at step 14. Later, when there is a UE activity (step 16), the SM-SC is informed via the HSS (step 18) that the UE is reachable and the SM-SC initiates a new delivery of the Device trigger (step 19, 20).
The 3GPP specification foresees 2 different identifiers for the MTC Device during the Device Triggering procedure. The first identifier is called external identifier (ID) and is used outside the 3GPP network, e.g. between the MTC server/application and the network, to uniquely identify a UE registered in the network. An example for external ID can be MSISDN (Mobile Subscriber Integrated Services Digital Network Number) used nowadays to uniquely identify GSM, UMTS, and/or LTE subscription. The second identifier is called internal identifier (ID) and is used within the 3GPP network to identify the UE subscription, to perform routing of messages within the network, etc. An example of an internal ID is the IMSI (International Mobile Subscriber Identity).
In Release 10 (Rel-10) of the 3GPP standardisation the congestion control mechanism in the network was extended with the NAS level congestion control. The introduction of NAS level congestion control was a result of the studies performed in 3GPP for the impact of Machine Type Communication to the network. It was concluded that the numerous MTC devices acting in simultaneous manner could cause congestion or overload to the network. The NAS level Congestion Control can be divided in “APN based congestion control” and “General NAS level Mobility Management control”. The APN based congestion control is applicable to UEs which are members of particular APN. The network can provide limitation of the maximum number of connections (bearers) or number of network accesses to the network for a particular APN. The General NAS level Mobility Management control is applicable when many UEs initiate network access attempts almost simultaneously which could cause a congestion in the serving CN node (MME/SGSN).
Both Session Management (SM) and Mobility Management (MM) are considered as sublayers of the NAS (Non-Access Stratum) layer in the UE and in the MME/SGSN. Usually the MME/SGSN and UE stores separate MM and SM contexts. Furthermore, the SM context is per PDP (Packet Data Protocol) or PDN (Packet Data Network) connection. If a UE has multiple PDP/PDN connections to different APNs, the UE would have 1 MM context and multiple SM contexts.
It is noted that in GPRS mobile networks, a separate packet data protocol (PDP) context is established in the SGSN for each separate tunnel (i.e. connection) for the UE. In EPS mobile networks, each packet data network (PDN) connection would result to a separate EPS bearer context in the MME. If generalized terminology for the mobile networks is used, i.e. GRPS and EPS networks, for simplicity it is easier to use the term PDP/PDN connection and PDP/PDN context (which would more precisely be denoted as PDP/EPS bearer context).
In the APN based Session Management congestion control, the SGSN/MME rejects Session Management (SM) requests from the UE when SM congestion associated with a given APN is detected. Optionally, the reject message can contain a Session Management back-off (SM BO) timer that then must be stored in the UE. If the UE has an SM-BO timer running, the UE shall not initiate any SM request to the MME/SGSN related to the given APN. With other words the UE is not able to establish new or modify existing PDP context or EPS bearers to the given APN during the SM-BO timer is running. The UE can still perform MM procedures, i.e. Tracking Area Update (TAU), Service Request etc. For easiness the general term SM request can be used to express all types of requests sent from the UE targeting the Session Management in SGSN/MME, such as PDN Connectivity, Bearer Resource Allocation or Bearer Resource Modification Requests, etc.
In the APN based Mobility Management congestion control, the MME/SGSN performs this control to UEs with a particular subscribed APN by rejecting Attach procedures with a Mobility Management back-off (MM-BO) timer.
In the general NAS level Mobility Management congestion control, MME/SGSN may reject Mobility Management signalling requests from UEs when the MME/SGSN experiences general overload conditions (e.g. no more processing power, the memory is occupied, or the maximum number of stored MM/SM contexts is about to be reached). The MME/SGSN can include a Mobility Management back-off (MM-BO) timer to the UE in the reject message.
For all cases of NAS-level congestion control, it is optional whether the network (SGSN/MME) sends an SM-BO timer (in case of APN-based SM CC) or MM-BO timer (in case of MM CC) in the corresponding reject message to the UE. Further, it is optional whether the SGSN/MME stores the sent SM-BO or MM-BO timer. For example, when the SGSN/MME rejects a new PDP context or PDN connection request, the SGSN/MME would not have PDP or PDN context for the UE and it would be difficult to store the SM-BO timer without having a corresponding context. However, if the UE already has a PDP/PDN context and the SGSN/MME rejects a Modification Request from the UE, the SGSN/MME would be able to store the SM-BO timer, as there is related context. More details to the congestion control may be found in Section 4.3.7.4.2 “NAS level congestion control” of 3GPP TS 23.401, v.10.5.0, September 2011, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN)”.
When NAS level congestion control is activated in the network, 3GPP TS 23.888 in Section 6.59 describes a solution how the Device Trigger requests sent from the MTC server can be limited. In this solution, the SGSN/MME (serving network node) activates over the T5 interface (between MTC-IWF and SGSN/MME) the overload control for limiting the sending rate of DT requests. However, this mechanism doesn't describe very precisely the impact of the APN-based SM congestion control, but rather is applicable for a general MM congestion control.
The APN-based SM congestion control (CC) is applied to the APN, to which a triggered UE is going to send UL data. When Device Trigger request is sent to a UE, the APN-based SM CC is applied to the UE signalling to establish or modify a PDP/PDN connection. There are basically two cases. The first case is when SM-BO timer is running in the UE at the time point of Device Triggering and the second case is when no SM-BO timer is running in the UE, however, when attempting to establish the PDP context, the UE obtains an SM reject message with an SM-BO timer.
When the UE receives the Device Trigger request including the network-opaque information, the UE processes (i.e. routes internally) the Trigger info to the correct Application. The UE determines that UL data has to be sent to a target APN. It is assumed that the target APN is under Session Management Congestion Control (SM CC). The UE may or may not be aware of the applied SM CC. The establishment of a connection to the target APN depends on the access network type (E-UTRA, UTRAN, GERAN) to which the UE is attached.
In the current E-UTRAN access, in order to transmit Device Trigger request to the UE, the EMM/RRC connection is established for downlink NAS message (carrying the Device Trigger request) and the U-plane bearers are established automatically. If there was a pre-established PDN connection (EPS bearer) to the target APN, UE could send UL data over U-plane without SM signalling to the MME/SGSN even if the target APN is congested. If there is no pre-established EPS bearer, UE cannot send UL data because the PDN connectivity request message for a new PDN connection or the EPS bearer modification message to modify an existing EPS bearer cannot be transmitted. It is noted that the SM congestion control is applied on the C-plane (control plane) signalling, and does not affect the U-plane (user plane). The UE is not able to send signalling to SGSN/MME (for instance, for the U-plane connection establishment or modification). However, for the already established U-plane connections the UE is able to send and receive data.
In GERAN/UTRAN access (also known as 2G/3G access), in order to transmit Device Trigger request to the UE, the MM/RRC connection is established for the downlink NAS message (which can carry e.g. MT-SMS or other type/format of Trigger request), but no U-plane bearers are established. The UE should establish or activate the PDP context separately using the NAS SM signalling request. If the SM-BO timer is running in the UE, the UE is not allowed to send an SM request, and thus, the UE cannot establish/activate the PDP context. Consequently, the UE is not able to send the UL data.
On the other hand, if the SM-BO timer is not running, the UE would send a NAS SM request message to establish a PDP context and the SGSN would reject this message if it is targeted to the congested APN. This is not efficient as paging is performed and radio resource connection (RRC) and NAS signalling connection are established for the device trigger request transmission and then released after the rejection oof the UE's NAS SM request. Therefore a solution is needed to avoid, where possible, the transmission of the device trigger request message.
In a further scenario related to the SM congestion control, the serving network node (SGSN/MME) may not be able to determine the following:                whether the received downlink message in the SGSN/MME (and addressed to the UE) is meant for Device Triggering (DT). This is especially applicable for the case where the DT request is carried in a Mobile Terminated SMS (MT-SMS). In this case, the SGSN/MME cannot determine whether the MT-SMS is a “normal” SMS or “DT-related” SMS that carries special information for triggering an MTC Application in the SMS body;        which is the target APN, i.e. to which APN the UE would establish/activate a user plane connection after receiving and processing the DT request. In this case the SGSN/MME cannot estimate whether the activated APN-based SM congestion control is applicable to the UE or not.        
Accordingly, the congestion control could not be performed efficiently in this scenario.
It is assumed that in the case when the SGSN/MME applies MM congestion control, the SGSN/MME would not page the UE when the Device Trigger request has to be transmitted. The reason is that through the paging, additional MM signalling to from the SGSN/MME would be caused, which is not desirable. Furthermore, if an MM back-off timer is running in the UE when the UE receives paging for the Device Trigger, the UE would delete the MM back-off timer and omit the MM congestion control. So, the SGSN/MME would probably not page the UE and the SGSN/MME would signal back to the SM-SC or to the MTC-IWF, depending whether T4 or T5 interface is used, that the Device Trigger request is not delivered. The MTC-IWF would generate a Trigger Delivery report, which may contain a cause value that the non-delivery is due to MM congestion control, and send it to the MTC server. The network (SM-SC of MTC-IWF) inform the MTC server about the congestion situation and requests the MTC server to limit (or stop) the transmission of the Device Trigger requests for a particular group of devices. This situation may lead to different problems.